The following contributors got their Debian Developer accounts in the last two months:
It finally happened
On the 6th of April 2017, I finally took the plunge and applied for Debian Developer status. On 1 August, during DebConf in Montr al, my application was approved. If you re paying attention to the dates you might notice that that was nearly 4 months ago already. I was trying to write a story about how it came to be, but it ended up long. Really long (current draft is around 20 times longer than this entire post). So I decided I d rather do a proper bio page one day and just do a super short version for now so that someone might end up actually reading it.
How it started
In 1999 no wait, I can t start there, as much as I want to, this is a short post, so In 2003, I started doing some contract work for the Shuttleworth Foundation. I was interested in collaborating with them on tuXlabs, a project to get Linux computers into schools. For the few months before that, I was mostly using SuSE Linux. The open source team at the Shuttleworth Foundation all used Debian though, which seemed like a bizarre choice to me since everything in Debian was really old and its boot-floppies installer program kept crashing on my very vanilla computers.
SLUG (Schools Linux Users Group) group photo. SLUG was founded to support the tuXlab schools that ran Linux.
Ubuntu 4.10 default desktop Image from distrowatch
DebConf16 Organisers, Photo by Jurie Senekal.
Similar to the problem described in the post
Google Hangouts in Debian testing (Buster), the Spotify application
for Debian (a package called spotify-client) is not ready to run in
Debian testing (Buster) as is.
In this particular case, it seems there is only one problem, and is related to
openssl/libssl. The spotify-client package requires libssl1.0.0 while in
Debian testing (Buster) we have an updated libssl1.1.
Fortunately, this is rather easy to solve, given the little additional
dependencies of both spotify-client and libssl1.0.0.
What we will do is to install libssl1.0.0 from jessie-backports, coexisting
with libssl1.1.
Simple steps:
/etc/apt/sources.list file: deb http://httpredir.debian.org/debian/ jessie-backports main
% user@debian:~ $ sudo aptitude update
libssl1.1 and libssl1.0.0 ready to install:
% user@debian:~ $ aptitude search libssl
[...]
p libssl1.0.0 - Secure Sockets Layer toolkit - shared libraries
i libssl1.1 - Secure Sockets Layer toolkit - shared libraries
[...]
spotify-client package: jessie-backports line from /etc/apt/sources.list.libssl1.0.0 package.
BTW, thanks to the openssl Debian maintainers, their work is really
appreciated :-) And thanks to Spotify for providing a Debian package :-)
From that, Bacon elaborates possible reasons for the apparent decline of the GPL. The graphic used in the article was actually generated by Stephen O'Grady in a January article, The State Of Open Source Licensing, which said:![[Black Duck histogram]](https://static.lwn.net/images/2017/debconf-blackduck.png)
In Black Duck's sample, the most popular variant of the GPL version 2 is less than half as popular as it was (46% to 19%). Over the same span, the permissive MIT has gone from 8% share to 29%, while its permissive cousin the Apache License 2.0 jumped from 5% to 15%.Sullivan, however, argued that the methodology used to create both articles was problematic. Neither contains original research: the graphs actually come from the Black Duck Software "KnowledgeBase" data, which was partly created from the old Ohloh web site now known as Open Hub. To show one problem with the data, Sullivan mentioned two free-software projects, GNU Bash and GNU Emacs, that had been showcased on the front page of Ohloh.net in 2012. On the site, Bash was (and still is) listed as GPLv2+, whereas it changed to GPLv3 in 2011. He also claimed that "Emacs was listed as licensed under GPLv3-only, which is a license Emacs has never had in its history", although I wasn't able to verify that information from the Internet archive. Basically, according to Sullivan, "the two projects featured on the front page of a site that was using [the Black Duck] data set were wrong". This, in turn, seriously brings into question the quality of the data:
I reported this problem and we'll continue to do that but when someone is not sharing the data set that they're using for other people to evaluate it and we see glimpses of it which are incorrect, that should give us a lot of hesitation about accepting any conclusion that comes out of it.Reproducible observations are necessary to the establishment of solid theories in science. Sullivan didn't try to contact Black Duck to get access to the database, because he assumed (rightly, as it turned out) that he would need to "pay for the data under terms that forbid you to share that information with anybody else". So I wrote Black Duck myself to confirm this information. In an email interview, Patrick Carey from Black Duck confirmed its data set is proprietary. He believes, however, that through a "combination of human and automated techniques", Black Duck is "highly confident at the accuracy and completeness of the data in the KnowledgeBase". He did point out, however, that "the way we track the data may not necessarily be optimal for answering the question on license use trend" as "that would entail examination of new open source projects coming into existence each year and the licenses used by them". In other words, even according to Black Duck, its database may not be useful to establish the conclusions drawn by those articles. Carey did agree with those conclusions intuitively, however, saying that "there seems to be a shift toward Apache and MIT licenses in new projects, though I don't have data to back that up". He suggested that "an effective way to answer the trend question would be to analyze the new projects on GitHub over the last 5-10 years." Carey also suggested that "GitHub has become so dominant over the recent years that just looking at projects on GitHub would give you a reasonable sampling from which to draw conclusions".
Indeed, GitHub published a report in 2015 that also seems to confirm MIT's popularity (45%), surpassing copyleft licenses (24%). The data is, however, not without its own limitations. For example, in the above graph going back to the inception of GitHub in 2008, we see a rather abnormal spike in 2013, which seems to correlate with the launch of the choosealicense.com site, described by GitHub as "our first pass at making open source licensing on GitHub easier". In his talk, Sullivan was critical of the initial version of the site which he described as biased toward permissive licenses. Because the GitHub project creation page links to the site, Sullivan explained that the site's bias could have actually influenced GitHub users' license choices. Following a talk from Sullivan at FOSDEM 2016, GitHub addressed the problem later that year by rewording parts of the front page to be more accurate, but that any change in license choice obviously doesn't show in the report produced in 2015 and won't affect choices users have already made. Therefore, there can be reasonable doubts that GitHub's subset of software projects may not actually be that representative of the larger free-software community.![[GitHub graph]](https://static.lwn.net/images/2017/debconf-github.png)
The long history of Debian creates a perfect subject to evaluate how FOSS licenses use has evolved over time, and the popularity of licenses currently in use.Sullivan argued that the Debsources data set is interesting because of its quality: every package in Debian has been reviewed by multiple humans, including the original packager, but also by the FTP masters to ensure that the distribution can legally redistribute the software. The existence of a package in Debian provides a minimal "proof of use": unmaintained packages get removed from Debian on a regular basis and the mere fact that a piece of software gets packaged in Debian means at least some users found it important enough to work on packaging it. Debian packagers make specific efforts to avoid code duplication between packages in order to ease security maintenance. The data set covers a period longer than Black Duck's or GitHub's, as it goes all the way back to the Hamm 2.0 release in 1998. The data and how to reproduce it are freely available under a CC BY-SA 4.0 license.
Sullivan presented the above graph from the research paper that showed the evolution of software license use in the Debian archive. Whereas previous graphs showed statistics in percentages, this one showed actual absolute numbers, where we can't actually distinguish a decline in copyleft licenses. To quote the paper again:![[Debsource graph]](https://static.lwn.net/images/2017/debconf-debsources.png)
The top license is, once again, GPL-2.0+, followed by: Artistic-1.0/GPL dual-licensing (the licensing choice of Perl and most Perl libraries), GPL-3.0+, and Apache-2.0.Indeed, looking at the graph, at most do we see a rise of the Apache and MIT licenses and no decline of the GPL per se, although its adoption does seem to slow down in recent years. We should also mention the possibility that Debian's data set has the opposite bias: toward GPL software. The Debian project is culturally quite different from the GitHub community and even the larger free-software ecosystem, naturally, which could explain the disparity in the results. We can only hope a similar analysis can be performed on the much larger Software Heritage data set eventually, which may give more representative results. The paper acknowledges this problem:
Debian is likely representative of enterprise use of FOSS as a base operating system, where stable, long-term and seldomly updated software products are desirable. Conversely Debian is unlikely representative of more dynamic FOSS environments (e.g., modern Web-development with micro libraries) where users, who are usually developers themselves, expect to receive library updates on a daily basis.The Debsources research also shares methodology limitations with Black Duck: while Debian packages are reviewed before uploading and we can rely on the copyright information provided by Debian maintainers, the research also relies on automated tools (specifically FOSSology) to retrieve license information. Sullivan also warned against "ascribing reason to numbers": people may have different reasons for choosing a particular license. Developers may choose the MIT license because it has fewer words, for compatibility reasons, or simply because "their lawyers told them to". It may not imply an actual deliberate philosophical or ideological choice. Finally, he brought up the theory that the rise of non-copyleft licenses isn't necessarily at the detriment of the GPL. He explained that, even if there is an actual decline, it may not be much of a problem if there is an overall growth of free software to the detriment of proprietary software. He reminded the audience that non-copyleft licenses are still free software, according to the FSF and the Debian Free Software Guidelines, so their rise is still a positive outcome. Even if the GPL is a better tool to accomplish the goal of a free-software world, we can all acknowledge that the conversion of proprietary software to more permissive and certainly simpler licenses is definitely heading in the right direction.
[I would like to thank the DebConf organizers for providing meals for me during the conference.] Note: this article first appeared in the Linux Weekly News.
 |
git-annex repository, with
some small edits to link to more source code:
A Debian maintainer's guide to Flatpak.
Source code for the slides
is also available from Collabora's git server.
The next step is to take my proof-of-concept for building
Flatpak runtimes and apps from Debian and SteamOS packages,
flatdeb, get it
a bit more production-ready, and perhaps start publishing some sample
runtimes from a cron job on a Debian or Collabora server. (By the way,
if you downloaded that source right after my talk, please update - I've
now pushed some late changes that were necessary to fix the 3D drivers
for my OpenArena demo.)
I don't think Debian will be going quite as far as
Endless any time soon: as
Cosimo outlined in the talk right before mine, they
deploy their Debian derivative as an immutable base OS with
libOSTree, with all the
user-installable modules above that coming from Flatpak. That model is
certainly an interesting thing to think about for Debian derivatives,
though: at Collabora we work on a lot of appliance-like embedded Debian
derivatives, with a lot of flexibility during development but very limited
state on deployed systems, and Endless' approach seems a perfect fit for
those situations.
[Edited 2017-08-16 to fix the link for the slides, and add links for the
video]
Debian needs feature X but it is already in the enterprise version. We make a patch and, for commercial reasons, it never gets merged (they already sell it in the enterprise version). Which means we will have to fork the software and keep those patches forever. Been there done that. For me, that isn't acceptable.This concern was further deepened when GitLab's Director of Strategic Partnerships, Eliran Mesika, explained the company's stewardship policy that explains how GitLab decides which features end up in the proprietary version. Praveen pointed out that:
[...] basically it boils down to features that they consider important for organizations with less than 100 developers may get accepted. I see that as a red flag for a big community like debian.Since there are over 600 Debian Developers, the community seems to fall within the needs of "enterprise" users. The features the Debian community may need are, by definition, appropriate only to the "Enterprise Edition" (GitLab EE), the non-free version, and are therefore unlikely to end up in the "Community Edition" (GitLab CE), the free-software version. Interestingly, Mesika asked for clarification on which features were missing, explaining that GitLab is actually open to adding features to GitLab CE. The response from Debian Developer Holger Levsen was categorical: "It's not about a specific patch. Free GitLab and we can talk again." But beyond the practical and ethical concerns, some specific features Debian needs are currently only in GitLab EE. For example, debian.org systems use LDAP for authentication, which would obviously be useful in a GitLab deployment; GitLab CE supports basic LDAP authentication, but advanced features, like group or SSH-key synchronization, are only available in GitLab EE. Wirt also expressed concern about the Contributor License Agreement that GitLab B.V. requires contributors to sign when they send patches, which forces users to allow the release of their code under a non-free license. The debate then went on going through a exhaustive inventory of different free-software alternatives:
On the mailinglist it seemed that some Debian maintainers do not agree with our open core business model and demand that there is no proprietary version. We respect that position but we don't think we can compete with the purely proprietary software like GitHub with this model.
Personally I'm leaning towards the feeling that all configuration, code and dependencies for Debian services should be packaged and subjected to the usual Debian QA activities but I acknowledge that the current archive setup (testing migration plus backporting etc) doesn't necessarily make this easy.Wise did say that "DSA doesn't have any hard rules/policy written down, just evaluation on a case-by-case basis" which probably means that pagure packaging will not be a blocker for deployment. The last pending issue is the question of the mailing lists hosted on Alioth, as pagure doesn't offer mailing list management (nor does GitLab). In fact, there are three different mailing list services for the Debian project:
Note: this article first appeared in the Linux Weekly News.
tl;dr: Get vmdebootstrap replacement from http://git.liw.fi/vmdb2 and
run it from the source tree. Tell me if something doesn't work. Send
patches.
Many years ago I wrote vmdebootstrap, a tool for installing Debian
on a disk image for virtual machines. I had a clear personal need: I
was setting up a CI system and it needed six workers: one each for
Debian oldstable, stable, and unstable, on two architectures (i386,
amd64). Installing Debian six times in the same way is a lot of work,
so I figured how difficult can it be to automate it. Turns out that
not difficult at all, except to install a bootloader.
(Don't ask me why I didn't use any of the other tools for this. It was
long ago, and while some of the tools that now exist probably did
exist then, I like writing code and learning things while doing it.)
After a while I was happy with what the program did, but didn't want
to upload it to Debian, and didn't want to add the kinds of things
other people wanted, so I turned vmdebootstrap over to Neil Williams,
who added a ton of new features. Unfortunately, it turned out that my
initial architecture was not scaleable, and also the code I wrote
wasn't very good, and there weren't any tests.
Neil did heroic work forcing my crappy software into doing things I never
envisioned. Last year he needed a break and asked me to take
vmdebootstrap back. I did, and have been hiding from the public eye
ever since, since I was so ashamed of the code. (I created a new
identity and pretended to be an international assassin and backup
specialist, travelling the world forcing people to have at least one
tested backup of their system. If you've noticed reports in the press
about people reporting near-death experiences while holding a shiny
new USB drive, that would've been my fault.)
Pop quiz: if you have a program with ten boolean options ("do this,
except if that option is given, do the other thing"), how many black
box tests do you need to test all the functionality? If one run of the
program takes half an hour, how long will a full test suite run?
I did some hard thinking about vmdebootstrap, and came to the sad
conclusion that it had reached the end of its useful life as a living
software project. There was no reasonable way to add most of the
additional functionality people were asking for, and even maintaining
the current code was too tedious a task to consider seriously. It was
time to make a clean break of the past and start over, without caring
about backwards compatibility. After all, the old code wasn't going
anywhere so anyone who needed it could still use it. There was no need
to burden a new program with my past mistakes. All new mistakes were
called for.
At the Cambridge mini-Debconf of November, 2016, I gave a short
presentation of what I was going to do. I also posted about my
plans to the debian-cloud list. In short, I would write a new, more
flexible and cleaner replacement to be called vmdb2. For various
personal reasons, I've not been able to spend as much time on vmdb2
as I'd like to, but I've now reached the point where I'd like to
announce the first alpha version publically.
The source code is hosted here: http://git.liw.fi/vmdb2 . There are
.deb packages at my personal public APT repo (http://liw.fi/code/),
but vmdb2 is easy enough to run directly from a git checkout:
sudo ./vmdb2 foo.vmdb --output foo.img
steps:
- mkimg: " output "
size: 4G
- mklabel: msdos
device: " output "
- mkpart: primary
device: " output "
start: 0%
end: 100%
part-tag: root-part
- mkfs: ext4
partition: root-part
- mount: root-part
fs-tag: root-fs
- unpack-rootfs: root-fs
- debootstrap: stretch
mirror: http://http.debian.net/debian
target: root-fs
unless: rootfs_unpacked
- apt: linux-image-amd64
fs-tag: root-fs
unless: rootfs_unpacked
- cache-rootfs: root-fs
unless: rootfs_unpacked
- chroot: root-fs
shell:
sed -i '/^root:[^:]*:/s//root::/' /etc/passwd
echo pc-vmdb2 > /etc/hostname
- grub: bios
root-fs: root-fs
root-part: root-part
device: " output "
console: serial
There is a thorny topic we have been discussing in nonpublic channels (say, the debian-private mailing list... It is impossible to call it a private list if it has close to a thousand subscribers, but it sometimes deals with sensitive material) for the last week. We have finally confirmation that we can bring this topic out to the open, and I expect several Debian people to talk about this. Besides, this information is now repeated all over the public Internet, so I'm not revealing anything sensitive. Oh, and there is a statement regarding Dmitry Bogatov published by the Tor project But I'll get to Tor soon.
One week ago, the 25-year old mathematician and Debian Maintainer Dmitry Bogatov was arrested, accused of organizing riots and calling for terrorist activities. Every evidence so far points to the fact that Dmitry is not guilty of what he is charged of He was filmed at different places at the times where the calls for terrorism happened.
It seems that Dmitry was arrested because he runs a Tor exit node. I don't know the current situation in Russia, nor his political leanings But I do know what a Tor exit node looks like. I even had one at home for a short while.
What is Tor? It is a network overlay, meant for people to hide where they come from or who they are. Why? There are many reasons Uninformed people will talk about the evil wrongdoers (starting the list of course with the drug sellers or child porn distributors). People who have taken their time to understand what this is about will rather talk about people for whom free speech is not a given; journalists, political activists, whistleblowers. And also, about regular people Many among us have taken the habit of doing some of our Web surfing using Tor (probably via the very fine and interesting TAILS distribution The Amnesiac Incognito Live System), just to increase the entropy, and just because we can, because we want to preserve the freedom to be anonymous before it's taken away from us.
There are many types of nodes in Tor; most of them are just regular users or bridges that forward traffic, helping Tor's anonymization. Exit nodes, where packets leave the Tor network and enter the regular Internet, are much scarcer Partly because they can be quite problematic to people hosting them. But, yes, Tor needs more exit nodes, not just for bandwidth sake, but because the more exit nodes there are, the harder it is for a hostile third party to monitor a sizable number of them for activity (and break the anonymization).
I am coincidentially starting a project with a group of students of my Faculty (we want to breathe life again into LIDSOL - Laboratorio de Investigaci n y Desarrollo de Software Libre). As we are just starting, they are documenting some technical and social aspects of the need for privacy and how Tor works; I expect them to publish their findings in El Nigromante soon (which means... what? ), but definitively, part of what we want to do is to set up a Tor exit node at the university Well documented and with enough academic justification to avoid our network operation area ordering us to shut it down. Lets see what happens :)
Anyway, all in all Dmitry is in for a heavy time. He has been detained pre-trial at least until June, and he faces quite serious charges. He has done a lot of good, specialized work for the whole world to benefit. So, given I cannot do more, I'm just speaking my mind here in this space.
[Update] Dmitry's case has been covered in LWN. There is also a statement concerning the arrest of Dmitry Bogatov by the Debian project. This case is also covered at The Register.
There have been a two long threads on the debian-devel mailing list
about the representation of the changes to upstream source code made
by Debian maintainers. Here are a few notes for my own reference.
I spent a lot of time defending the workflow I described in
dgit-maint-merge(7) (which was inspired by this blog post).
However, I came to be convinced that there is a case for a manually
curated series of patches for certain classes of package. It will
depend on how upstream uses git (rebasing or merging) and on whether
the Debian delta from upstream is significant and/or long-standing. I
still think that we should be using dgit-maint-merge(7) for leaf or
near-leaf packages, because it saves so much volunteer time that can
be better spent on other things.
When upstream does use a merging workflow, one advantage of the
dgit-maint-merge(7) workflow is that Debian s packaging is just
another branch of development.
Now consider packages where we do want a manually curated patch
series. It is very hard to represent such a series in git. The only
natural way to do it is to continually rebase the patch series against
an upstream branch, but public branches that get rebased are not a
good idea. The solution that many people have adopted is to represent
their patch series as a folder full of .diff files, and then use
gbp pq to convert this into a rebasing branch. This branch is not
shared. It is edited, rebased, and then converted back to the folder
of .diff files, the changes to which are then committed to git.
One of the advantages of dgit is that there now exists an official,
non-rebasing git history of uploads to the archive.
It would be nice if we could represent curated patch series as
branches in the dgit repos, rather than as folders full of .diff
files. But as I just described, this is very hard. However, Ian
Jackson has the beginnings of a workflow that just might
fit the bill.
Welp I seem to have spent holidays of 1996 doing my first Debian package. The process of getting a package into Debian was quite straightforward then. "I have packaged fte, here is my pgp, can I has an account to upload stuff to Debian?" I think the bureaucracy took until second week of January until I could actually upload the created package.
fte (0.44-1) unstable; urgency=low
* initial Release.
-- Riku Voipio Wed, 25 Dec 1996 20:41:34 +0200
A few months after joining, someone figured out that to pgp signatures to be useful, keys need to be cross-signed. Hence young me taking a long bus trip from countryside Finland to the capital Helsinki to meet the only other DD in Finland in a cafe. It would still take another two years until I met more Debian people, and it could be proven that I'm not just an alter ego of Lars ;) Much later an alternative process of phone-calling prospective DD's would be added.
uid Riku Voipio
sig 89A7BF01 1996-12-15 Riku Voipio
sig 4CBA92D1 1997-02-24 Lars Wirzenius
Next.